In the field of communications, particularly but not exclusively wireless communications, it is known to communicate data in datagrams, the datagrams traversing a communications network from a source node to a destination node or a communications fabric between the source node and the destination node. In order to ensure reliable communication of the datagrams between the source node and the destination node, a so-called flow control protocol is employed. The flow control protocol is usually one of a number of protocols employed in a communications system between the source and destination nodes. In this respect, an Open Systems Interconnection model is a common reference model for a so-called protocol stack employed at the source and destination nodes. In relation to flow control, a common protocol employed is a Transmission Control Protocol (TCP), which is one of the core protocols of an Internet Protocol suite. The TCP is defined over a number of Requests for Comments (RFCs) available from the Internet Engineering Task Force (IETF). One aspect of the TCP is congestion avoidance as defined in RFC 2581.
Electronic devices, for example portable communications devices, comprise so-called “application processors” that receive the datagrams, for example TCP segments, and confirm receipt of the TCP segments by sending acknowledgement messages (ACKs) respectively in reply to the receipt of the TCP segments in order to confirm receipt thereof. Furthermore, the electronic devices are usually powered by portable power sources, for example rechargeable cells, the capacity or remaining charge of which needs to be conserved as much as possible to enable the electronic device to operate for as long a period of time as possible. The application processor therefore usually implements a number of power conservation measures in the form of modes of operation that consume varying amounts of electrical power, for example: a Wait or Doze mode, a Stop mode and/or a Sleep Mode. In some circumstances, the provision of the sleep mode in respect of the application processor enables the electronic device to enter a so-called “Deep Sleep Mode”, whereby the electronic device can conserve energy.
In one known scenario, a processing resource within a communications network, for example a in a Node B of a Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), receives TCP segments from a source node attached or coupled to the Internet at a rate of receipt. The TCP segments are addressed to a destination node associated with the application processor of the electronic device. In this example, the electronic device is a User Equipment (UE) unit of a UMTS communications network. The Node B is therefore used to transmit the TCP segments to the UE over a Radio Frequency (RF) interface of the TCP segments by the UTRAN. At the UE unit, a modem processor of the UE unit receives the TCP segments at a rate corresponding to the rate of receipt. The modem processor communicates the received TCP segments to the application processor of the UE at a corresponding rate of receipt.
Referring back to the power saving features of the application processor, in order to be able to enter the Sleep Mode and therefore conserve maximum electrical power, a sufficient amount of time has to elapse during which data is not received by the application processor before the Sleep Mode can be entered by the application processor. If TCP segments are being received at a sufficiently fast rate that the application processor does not remain idle for the necessary amount of time required for the Sleep Mode to be entered, the application processor simply transitions between the lesser power conserving Wait and Stop modes. Consequently, the application processor does not get an opportunity to enter the sleep mode and less power is conserved by the UE and hence battery life is reduced.
Additionally, repeated interruption of the application processor in order to process TCP segments and transmit ACKs back to the source node via the modem processor consumes Millions of Cycles Per Second (MCPS) of the application processor. As the application processor is only capable of supporting a finite number of MCPS, consumption of the MCPS in relation to generation of ACKs and processing of received TCP segments results in a corresponding reduction in the available MCPS for other applications, for example: video telephony, Internet browsing and/or voice switched telephony. Consequently, if insufficient MCPS are available, data throughput in respect of receipt of TCP segments is reduced. Additionally, the quality of one or more of the applications being supported by the application processor will have to be downgraded in order for sufficient MCPS to be available to support all applications running.
In order to reduce transmission of ACKs and hence attempt to improve performance efficiency, it is known to employ various ACK filtering techniques, for example as described in U.S. Pat. Nos. 6,078,564 and 6,438,108. However, such techniques sacrifice the Quality of Service (QoS) associated with communication of the TCP segments when multiple streams of data are employed. Furthermore, filtering of the ACKs consumes MCPS, because the application processor has to “read into” the TCP ACKs. As filtering of ACKs can only be supported correctly using “byte counting”, implementation of ACK counting in TCP stacks reduce data throughput in the communications network. Also, ACK filtering creates bursts of ACKs that reduces throughput. Consequently, RFC specifications do not recommend use of ACK filtering except in cases of asynchronous communications links. Additionally, ACK filtering does not work with the IPSEC suite of protocols for securing Internet Protocol (IP), and when the so-called “SACK” option is employed, as in 2.5G, 3G, 3.5G and Wireless Local Area Network standards.